The development of technologies to determine the position of a mobile device has enabled application developers and wireless network operators to provide location-based and location-aware services. Examples of these are guiding systems, shopping assistance, friend finder, presence services, community and communication services and other information services that give the mobile user information about his or her surroundings or that use this information to enhance their services.
In addition to the commercial services facilitated by these technologies, location-based emergency services are also being deployed. The governments in several countries have put specific requirements on the network operators to be able to determine the position of an emergency call. For instance, governmental requirements in the United States specify that mobile networks must be able to determine the position of a certain percentage of all emergency calls and further include accuracy requirements. The requirements make no distinctions between indoor and outdoor environment.
In many environments, the position can be accurately estimated by using positioning methods based on Global Navigation Satellite Systems (GNSS), such as the well-known Global Positioning System (GPS). However, GPS-based positioning may often have unsatisfactory performance, especially in urban and/or indoor environments. Complementary positioning methods may also be provided by a wireless network to augment GPS technology. In addition to mobile terminal-based GNSS (including GPS), the following methods are currently available or will be soon be included in the Long-Term Evolution (LTE) standards developed by the 3rd-Generation Partnership Project (3GPP):                Cell ID (CID),        E-CID, including network-based angle-of-arrival (AoA),        Assisted-GNSS (A-GNSS), including Assisted-GPS (A-GPS), based on satellite signals,        Observed Time Difference of Arrival (OTDOA),        Uplink Time Difference of Arrival (UTDOA)—being currently standardized.        
Several positioning techniques are based on time-difference-of-arrival (TDOA) or time-of-arrival (TOA) measurements. Examples include OTDOA, UTDOA, GNSS, and Assisted-GNSS (A-GNSS). A typical, though not the only, format for the positioning result with these techniques is an ellipsoid point with an uncertainty circle/ellipse/ellipsoid, which is the result of intersection of multiple hyperbolas/hyperbolic arcs (e.g., OTDOA or UTDOA) or circles/arcs (e.g., UTDOA, GNSS, or A-GNSS).
Several techniques, such as Adaptive Enhanced Cell Identity (AECID), may involve a mix of any of the methods above, and are thus regarded as “hybrid” positioning methods. With these methods, the position result can be almost any shape, but in many cases it is likely to be a polygon.
Cellular-based positioning methods (as opposed to satellite-based methods, for example) rely on knowledge of anchor nodes' locations, i.e., the fixed locations from which measured signals are transmitted (e.g., for OTDOA) or the fixed locations at which signals transmitted by mobile devices are measured (e.g., for UTDOA). These fixed locations may correspond, for example, to base station or beacon device locations for OTDOA, Location Measurement Unit (LMU) antenna locations for UTDOA, and base station locations for E-CID. The anchor nodes' location may also be used to enhance AECID, hybrid positioning, etc.
Uplink Positioning
In 3GPP, location-based services are known as Location Services (LCS). Three key network elements in an LTE positioning architecture are the LCS Client, the LCS target and the LCS Server. The LCS Server is a physical or logical entity that manages positioning for a LCS target device by collecting measurements and other location information, assists the target device in measurements when necessary, and estimating the LCS target location. A LCS Client is a software-based and/or hardware entity that interacts with a LCS Server for the purpose of obtaining location information for one or more LCS targets, i.e., the entities being positioned. LCS Clients may reside in a network node, an external node (i.e., a network external to a cellular network), a Public Safety Access Point (PSAP), a user equipment (or “UE,” 3GPP terminology for an end-user wireless station), a radio base station, etc. In some cases, the LCS Client may reside in the LCS target itself. An LCS Client (e.g., an external LCS Client) sends a request to LCS Server (e.g., a positioning node) to obtain location information. The LCS Server processes and services the received requests and sends the positioning result (sometimes including a velocity estimate) to the LCS Client.
In some cases, the position calculation is conducted by a positioning server, such as an Enhanced Serving Mobile Location Center (E-SMLC) or a Secure User-Plane Location (SUPL) Location Platform (SLP) in LTE. In other cases, the position calculation is carried out by the UE. The latter approach is known as the UE-based positioning mode, while the former approach includes both network-based positioning, i.e., position calculation in a network node based on measurements collected from network nodes such as LMUs or eNodeBs, and UE-assisted positioning, where the position calculation in the positioning network node is based on measurements received from UE.
LTE Positioning Protocol (LPP) is a positioning protocol for control plane signaling between a UE and an E-SMLC, which is used by the E-SMLC to provide assistance data to the UE and by the UE for reporting measurements to the E-SMLC. LPP has been designed in such a way that it can also be utilized outside the control plane domain such as in the user plane in the context of SUPL. LPP is used for DL positioning.
LTE Positioning Protocol Annex (LPPa), sometimes referred to as LTE Positioning Protocol A, is a protocol between the eNodeB and the E-SMLC, and is specified only for control-plane positioning procedures, although it still can assist user-plane positioning by querying eNodeBs for information (e.g., PRS configuration in a cell for OTDOA or UE SRS configuration for UTDOA) and/or eNodeB measurements. LPPa may be used for DL positioning and UL positioning.
FIG. 1 illustrates the UTDOA architecture currently under discussion in 3GPP, including nodes found in the Radio Access Network (RAN) and the core network, as well as an external LCS Client. Although uplink (UL) measurements may in principle be performed by any radio network node, such as the illustrated LTE eNodeB 110, the UL positioning architecture also includes specific UL measurement units, known as Location Measurement Units (LMUs), which are logical and/or physical nodes that measure signals transmitted by a target UE, such as the UE 130 illustrated in FIG. 1. Several LMU deployment options are possible. For example, referring to FIG. 1, LMU 120a is integrated into eNodeB 110, while LMU 120b shares some equipment, e.g., at least antennas, with eNodeB 110. LMU 120c, on the other hand, is a standalone physical node comprising its own radio components and antenna(s).
While the UTDOA architecture is not finalized, there will likely be communication protocols established for communications between a LMU and positioning node, and there may be some enhancements to support UL positioning added to the existing Location Position Protocol Annex (LPPa) or to similar protocols. LPPa is a protocol between an eNodeB and an LCS Server specified only for control-plane positioning procedures, although it can be used to assist user-plane positioning by querying eNodeBs for information and eNodeB measurements.
In particular, a new interface between the E-SMLC and LMU is being standardized for uplink positioning. This interface, known as SLm, is terminated between a positioning server, e.g., the E-SMLC 140 pictured in FIG. 1, and an LMU. It is used to transport messages according to the SLmAP protocol, a new protocol being specified for UL positioning, between the E-SMLC and the LMU. SLmAP can be used to provide assistance data to an LMU, as discussed in further detail below. This protocol amy also be used by the LMU to report to the E-SMLC results of measurements on radio signals performed by the LMU. The SLmAP protocol was previously referred to as the LMUp protocol; thus is should be understood that references herein to SLmAP are referring to a developing protocol referred to as LMUp elsewhere.
In LTE, UTDOA measurements, known as UL relative time-of-arrival (RTOA) measurements, are performed on Sounding Reference Signals (SRS). To detect an SRS signal, an LMU 120 needs a number of SRS parameters to generate an SRS sequence that is correlated against the received signal. These parameters are not necessarily known to LMU 120. Thus, to allow the LMU to generate the SRS sequence and detect the SRS signals transmitted by a UE, SRS parameters must be provided in the assistance data transmitted by the positioning node to LMU; these assistance data would be provided via SLmAP. However, the SRS parameters are also generally unknown to the positioning node, which therefore must obtain this information from the eNodeB that configured the target UE to perform the SRS transmissions to be measured by the LMU; this information would have to be provided to the positioning node via LPPa or a similar protocol.
The specific contents of the assistance data provided to LMUs by a positioning node, over SLmAP, are currently being discussed in 3GPP. One intention of the assistance data is to indicate the SRS configuration for the uplink signals that the LMUs will measure. One example of the specific assistance data that might be provided to an LMU by a positioning node, using SLmAP, is shown in Table 1. This assistance data, which can be based on information provided to the E-SMLC by an eNodeB, can be used by the LMU to configure UL RTOA measurements, for example.
TABLE 1Parameter CategoryParametersGeneralC-RNTIServing eNB eCGI, PCIUL-EARFCNCyclic prefix ConfigUL-BandwidthSRSBandwidthSub-frame configurationFrequency domain positionCyclic shiftDurationTransmission combConfiguration indexMaxUpPts
Since the eNodeB is configuring UE transmissions in general, including the SRS transmissions, it has to communicate to the positioning node the configuration information for the UL transmissions to be measured for UL positioning. It has been proposed that the same configuration information signaled to LMUs by the positioning node is proposed to be also signaled from the eNodeB to the E-SMLC.
Measurements for UL positioning and UTDOA are performed on UL transmissions, which may include, for example, reference signal transmissions or data channel transmissions. UL RTOA is the currently standardized UTDOA timing measurement, and may be performed on Sounding Reference Signals (SRS). The results of the measurements are signaled by the measuring node (e.g., LMU) to the positioning node (e.g., E-SMLC), e.g., over SLmAP.
A positioning result is a result of processing of obtained measurements, including Cell IDs, power levels, received radio signal strengths or quality, etc. The positioning result is often based on radio measurements (e.g., timing measurements such as timing advance and RTT or power-based measurements such as received signal strength) received from measuring radio nodes (e.g., UE or eNodeB or LMU).
The positioning result may be exchanged among nodes in one of several pre-defined formats. The signaled positioning result is represented in a pre-defined format, e.g., corresponding to one of the seven Universal Geographical Area Description (GAD) shapes. Currently, a positioning result may be signaled between:                an LCS target, e.g., a UE, and an LCS server, e.g., over LPP protocol;        two positioning nodes, e.g., an E-SMLC or SLP, e.g., over a proprietary interface;        a positioning server (such as an E-SMLC,) and other network nodes, e.g., a Mobility Management Entity (MME), a Mobile Switching Center (MSC), a Gateway Mobile Location Center (GMLC), an Operations and Maintenance (O&M) node, a Self-Organizing Network (SON) node, and/or a Minimization of Drive Tests (MDT) node;        a positioning node and an LCS Client, e.g., between an E-SMLC and a Public Safety Access Point (PSAP), or between an SLP and an External LCS Client, or between an E-SMLC and a UE.Note that in emergency positioning, the LCS Client may reside in a PSAP.        
The LCS positioning quality in a positioning result is controlled by target quality requirements known as positioning quality-of-service (QoS), LCS QoS, or target LCS QoS. Positioning QoS may be described by any one or more of: a target horizontal uncertainty, a target vertical uncertainty, and a target response time. The uncertainty information, either horizontal or vertical, typically comprises an accuracy level and a corresponding confidence level.
The specific LCS QoS for a given positioning event depends on the service that is requesting positioning. There may also be pre-defined QoS configurations for specific LCS Client Types and/or LCS Service Types. The LCS QoS may be signaled by a LCS Client to other nodes. In LTE, an E-SMLC may receive this information from an MME, which in turn may receive it from GMLC.
For positioning techniques based on downlink measurements, the LCS QoS is communicated to a UE performing positioning measurements. More specifically, in the existing LTE specifications, it is signaled from E-SMLC to UE over LPP in the commonIEsRequestLocationInformation element to control UE-based positioning (i.e., when the positioning result is calculated by the UE; currently, for LTE there is only one standardized UE-based positioning method—A-GNSS) and it is essentially the information received by E-SMLC in a positioning request for the UE. The specifications require that QoS requirements shall be met by the target device to the degree possible. However, it is permitted to return a response that does not fulfill all QoS requirements, if some were not attainable. The single exception to this is the response-time requirement, which must always be fulfilled—even if that means not fulfilling other QoS requirements.
As mentioned above, the LCS QoS is also communicated between network nodes, in addition to being communicated to the UE for downlink UE-based positioning. The positioning node (e.g., the E-SMLC for control-plane positioning) receives a positioning request in an LCS-AP request message from the MME. This message is sent by the MME to request a location estimate for a target UE and contains sufficient information, including LCS QoS information, to enable location according to the target QoS, using any positioning method supported. The message is also used to request LCS assistance data transfer to a UE. This message is specified in the 3GPP document “Location Services (LCS); LCS Application Protocol (LCS-AP) between the Mobile Management Entity (MME) and Evolved Serving Mobile Location Centre (E-SMLC); SLs interface,” 3GPP TS 29.171, v. 11.1.0 (March 2012), available at www.3gpp.org. In particular, this Location Request Message includes LCS QoS parameters, which may specify horizontal accuracy, vertical accuracy and allowed response time for the requested positioning.
Positioning measurements are complicated by the recent development of multi-carrier techniques for cellular networks. A multi-carrier system, alternatively called a carrier aggregation (CA) system, allows a UE to simultaneously receive and/or transmit data over more than one distinct and separately configured carrier frequency. Each carrier frequency is often referred to as a component carrier (CC) or is referred to simply as a serving “cell” in the serving sector. More specifically, an individual carrier may be referred to as a primary serving cell or a secondary serving cell.
The multi-carrier concept is used in both High-Speed Packet (HSPA) systems and LTE systems. Carrier aggregation, or CA, is supported for both contiguous and non-contiguous component carriers. Carriers originating from the same eNodeB need not to provide the same coverage. Carriers in a multi-carrier system may also belong to different radio access technologies (RATs).
For a UE in RRC_CONNECTED mode that is not configured with CA, there is only one serving cell comprising of the primary cell. For a UE in RRC_CONNECTED mode and configured with carrier aggregation, the term “serving cells” is used to denote the set of one or more cells configured for the UE, which include the primary cell and all secondary cells.
The primary cell (PCell) is a configured cell, operating on the primary carrier frequency, also referred to as the primary component carrier (PCC), in which the UE either performs the initial connection establishment procedure or initiates the connection re-establishment procedure, or the cell indicated as the primary cell in the handover procedure. A secondary cell (SCell) is a cell, operating on a secondary carrier frequency, also referred to as a secondary component carrier (SCC), which may be configured after an RRC connection is established, and which may be used to provide additional radio resources in either the uplink or downlink directions, or both.
In the downlink, the carrier corresponding to the PCell is the Downlink Primary Component Carrier (DL PCC), while in the uplink it is the Uplink Primary Component Carrier (UL PCC). Depending on UE capabilities, SCells can be configured to form, together with the PCell, a set of serving cells. In the downlink, the carrier corresponding to an SCell is a Downlink Secondary Component Carrier (DL SCC), while in the uplink it is an Uplink Secondary Component Carrier (UL SCC). A set of configured serving cells in CA always includes one PCell and one or more SCells. The configured sets may be different in DL and UL.
In a CA system, the base station (e.g., eNode B) in LTE can selectively activate and deactivate one or more secondary cells on the corresponding secondary carriers. Thus, a secondary carrier may be selectively configured and deconfigured, and an activated secondary carrier may be selectively activated and deactivated. The UE may perform measurements on configured but not activated SCCs; however, the UE can transmit only on configured and activated SCCs. SCCs may be activated and deactivated dynamically. The activation and deactivation is done by the eNodeB using lower layer signaling (e.g., over PDCCH in LTE) using a short command such as ON/OFF, e.g., using 1 bit for each SCell. The activation/deactivation command is sent to the UE via the PCell. Typically deactivation is done when there is no data to transmit on the SCell(s). The activation/deactivation can be done independently on uplink and downlink SCell. One purpose of the deactivation is to enable UE battery saving.
While current standards for LTE specify the use of LCS QoS information for downlink measurements, improvements to uplink positioning techniques are needed.